Software production is a growth industry because of the worldwide commercial demand for computerized solutions to customer requirements in many different market segments. Some computer users have substantial programming skills, but the computer has become a tool that often is employed by users who lack the skills and/or motivation to engage in extensive computer programming. For that reason, software suppliers have invested substantial effort and expense in developing user interfaces that permit users to focus on applying computers to their intended tasks. Graphical user interfaces and window packages are notable examples of the software systems that now are being offered to facilitate the use of computers by persons ranging from non-technical users to highly skilled computer professionals. However, that system level software does not, in itself, permit of substantial differentiation between the diverse interface needs and preferences of different users.
Features of software user interfaces that are essential to one user may needlessly occupy space on another user's display screen. Likewise, some users need features that were not included by the application programmer. Consequently, some software packages have customizable user interfaces. For instance, there are packages that offer a variety of predefined interface options, so that users may customize their interfaces by selectively activating certain of the options to the exclusion of the others. Even more directly relevant to this invention, there are software packages that include tools which enable users to create active buttons and menus for causing the computer to perform functions in direct support of the users' individual needs and preferences.
More particularly, the HyperCard program enables users to create personalized buttons, forms and layouts. It supports the so-called HyperTalk language to allow users to program such buttons. See D. Goodman, The Complete HyperCard Handbook, Bantam Books, 1987. Similarly, the Xerox ViewPoint product supports a language called CUSP for programing buttons that can be inserted into documents. See VP CUSP Buttons Reference, VP Series Reference Library, Version 2.0, Xerox ViewPoint, Xerox Corporation, 1988. These CUSP buttons can be programmed to move icons and windows, as well as to print files, fill in forms, organize information into electronic file folders, and assist in performing other tasks. Spreadsheet programs also are of some interest because they conventionally permit the user to program in the equations for performing the calculations that the user wishes to have performed.
The so-called Andrew document editor is still another interesting example of the current state of the art because it permits buttons to be included in documents, to be transmitted via electronic mail, and to be employed by recipients of such mail messages. See J. H. Morris et al., "Andrew: A Distributed Personal Computing Environment," Communications of the ACM, Vol. 29, No. 3, March 1986, pp. 184-201. Furthermore, the Xerox Interlisp environment has a window manager, called "Rooms," which allows the user to create buttons for switching from "room-to-room" (i.e., from one user assembled collection of files and processing tools to another or, in other words, from one "desktop" to another), for starting up application programs, for recording a program state and later restoring it, and for performing other functions the user may wish to automate. See A. MacLean et al., "User Tailorable Systems: Pressing the Issues with Buttons," Human Factors in Computing Systems, Proceedings of CHI '90, April 1990, pp. 175-182. The Rooms supported buttons can be transferred via electronic mail to other users who are employing the Xerox Interlisp environment, and can be incorporated into a user's desktop to become a permanent part of the user's workstation environment. Moreover, these buttons can be customized by editing the LISP programming language functions they embody or by using menu commands to change their position and/or appearance.
As a general rule, the buttons the prior art has provided for the customization of user interfaces have been application specific, rather than being tools that can be shared by a variety of different applications. This is a significant disadvantage because most users find that they only have a limited amount of display screen space that they are willing to allocate to customized buttons at any given time, even though the users may be performing functions which cause them to switch back and forth frequently between different applications. Furthermore, when a user is employing an application that does not permit such buttons to be embedded in it, the custom buttons the user may want to employ must be spatially separated from the application on the user's display screen, thereby adding to the burden on the display screen space and also forcing the user to shift attention back and forth between the application space and the button space.
Still another disadvantage of the prior proposals for using buttons to customize user interfaces is that when such buttons are embedded in applications, the embedded buttons are treated as "special'" objects.
Therefore, even though a button residing in a text document might itself be a string of text, the editing of the button requires the use of different operations than are employed for editing the text in which the button resides. Moreover, an ordinary textual search operation will not find such a button, even if its text string matches the search pattern, because the button is not recognized as being a textual component of the document.